[newchem-cpp] generalize experimental ratequery API #477
+3,259
−591
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For context, the gmock library is a component of googletest (it's already being installed). All this commit does is make it possible for us to use it in subsequent PRs
This change ensures that the chemistry_data extension type will provide a consistent set of attributes, even if we make unused rate information inaccessible through the ratequery interface
… the ratequery API
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To be reviewed after #476 has been merged
This PR updates the experimental
ratequeryapi so that it can:PointerUniontype was introduced to help make this work nicelyTo help implement this machinery, I also introduced the
SimpleVectype since the basic bookkeeping of growable lists was getting a little out of hand (frankly, I think it would probably be better to just usestd::vectorfor this purpose, but I have left that debate for the future).I also needed to modify the accessible properties to check both (i) the type of entry and (ii) whether the entry is mutable. Obviously, I also had to introduce a function to read strings.
Overall, I'm not thrilled with how complex the
ratequerylogic has gotten. I do have some ideas for simplifying things... (I actually added a bunch of notes to the docstring). But, I think requires developing other parts of the API. So, for the near -ish term, I think it's a useful crutch.Note
This PR doesn't actually introduce any entries to actually leverage this new functionality. That will be the subject of the next PR in this sequence
Footnotes
Lists of strings will commonly fall into this category. But as another example, consider the yields of metal nuclides for each injection pathways. Yes, right now we use these yields in make_consistent. But, in the near future, we expect that to change, and we will simply enforce that the abundances at the start and end of a timestep are consistent. When we make this change, we will want to make the assumed abundances available to users in case external simulation codes want to achieve better consistency with the injection models ↩